home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Apple II Technical Notes / Technical.Notes / PDOS / TN.PDOS.020 < prev    next >
Encoding:
Text File  |  1988-12-15  |  6.0 KB  |  113 lines  |  [TEXT/pdos]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5.  
  6.  
  7. ProDOS 8
  8. #20:    Mirrored Devices and SmartPort
  9.  
  10. Revised by:    Matt Deatherage                                  November 1988
  11. Written by:    Matt Deatherage                                       May 1988
  12.  
  13. This Technical Note describes how ProDOS 8 reacts when more than two SmartPort 
  14. devices are connected, how applications using direct device access should 
  15. behave, and other related issues.  This Note supersedes Section 6.3.1 of the 
  16. ProDOS 8 Technical Reference Manual.
  17. _____________________________________________________________________________
  18.  
  19. Although SmartPort theoretically can handle up to 127 devices connected to a 
  20. single interface (in practice, electrical considerations curtail this 
  21. considerably), ProDOS 8 can handle only two devices per slot.  This is because 
  22. ProDOS uses bit 7 of its unit_number is used to distinguish drives from each 
  23. other, and a single bit cannot distinguish more than two devices.
  24.  
  25. When it boots, ProDOS checks each interface card (or firmware equivalent in 
  26. the IIc or IIGS) for the ProDOS block-device signature bytes ($Cn01 = $20, 
  27. $Cn03 = $00, and $Cn05 = $03), so it can install the appropriate device-driver 
  28. address in the system global page.  If the signature bytes match, ProDOS then 
  29. checks the SmartPort signature byte ($Cn07 = $00), and if that byte matches 
  30. and the interface is in slot 5 (or located at $C500 in the IIc or IIGS), 
  31. ProDOS does a SmartPort STATUS call to determine how many devices are 
  32. connected to the interface.  If only one or two drives are connected to the 
  33. interface, ProDOS installs its block-device entry point (the contents of $CnFF 
  34. added to $Cn00) in the device-driver vector table, which starts at $BF10.  In 
  35. this particular instance, ProDOS would put the vector at $BF1A for slot 5, 
  36. drive 1, and if two drives were found, at $BF2A for slot 5, drive 2 .
  37.  
  38. If the interface is in slot 5 and more than two devices are connected, ProDOS 
  39. copies the same block-device entry point that it uses for slot 5, drives 1 and 
  40. 2 in the device driver table entry for slot 2, drive 1, and if four drives are 
  41. connected, for slot 2, drive 2.  Further in the boot process, if ProDOS finds 
  42. the interface of a block device in slot 2 (not possible on a IIc), it replaces 
  43. the vectors copied from slot 5 with the proper device-driver vectors for slot 
  44. 2; this is the reason mirroring is disabled if there is a ProDOS device in 
  45. slot 2.  Note that non-ProDOS devices (i.e, serial cards and ports, etc.) do 
  46. not have vectors installed in the ProDOS device-driver table, so they do not 
  47. interfere with mirroring.
  48.  
  49. When ProDOS makes an MLI call with the unit_number of a mirrored device, it 
  50. sets up the call to the device driver then goes through the vector in the 
  51. device-driver table starting at $BF00.  When the block device driver (located 
  52. on the interface card or in the firmware) gets this MLI call, it checks the 
  53. unit number which is stored at $43 and verifies if the slot number (bits four, 
  54. five, and six) is the same as that of the interface.  If it is not, the ProDOS 
  55. block device driver of the interface realizes it is dealing with a mirrored 
  56. device, internally adds three to the slot number and two to the drive number, 
  57. then processes it, returning the desired information or data to ProDOS.
  58.  
  59. If an application must make direct device-driver calls (something which is 
  60. not encouraged), it should first check devlst (starting at $BF32) to verify 
  61. that the unit_number is from an active device.  In addition, the application 
  62. should mask off or ignore the low nibble of entries in devlst and know that 
  63. one less than the number of devices in the list is stored at $BF31 (devcnt).  
  64. The application then should use the unit_number to get the proper device-
  65. driver vector from the ProDOS global page; the application should not 
  66. construct the vector itself, because this vector would be invalid for a 
  67. mirrored device.
  68.  
  69. The following code fragment correctly illustrates this technique.  It is 
  70. written in 6502 assembly language and assumes the unit_number is in the 
  71. accumulator.
  72.  
  73. devcnt    equ    $BF31
  74. devlst    equ    $BF32
  75. devadr    equ    $BF10
  76. devget    sta    unitno       ; store for later compare instruction
  77.           ldx    devcnt       ; get count-1 from $BF31
  78. devloop   lda    devlst,x     ; get entry in list
  79.           and    #$F0         ; mask off low byte
  80. devcomp   cmp    unitno       ; compare to the unit_number we filled in
  81.           beq    goodnum      ;
  82.           dex
  83.           bpl    devloop      ; loop again if still less than $80
  84.           bmi    badunitno    ; error: bad unit number
  85. goodnum   lda    unitno       ; get good copy of unit_number
  86.           lsr    a            ; divide it by 8
  87.           lsr    a            ; (not sixteen because devadr entries are
  88.           lsr    a            ; two bytes wide)
  89.           tax
  90.           lda    devadr,x     ; low byte of device driver address
  91.           sta    addr
  92.           lda    devadr+1,x   ; high byte of device driver address
  93.           sta    addr+1
  94.           rts
  95. addr      dw     0            ; address will be filled in here by goodnum
  96. unitno    dfb    0            ; unit number storage
  97.  
  98. Similarly, applications which construct firmware entry points from user input 
  99. to "slot and drive" questions will not work with mirrored devices.  If an 
  100. application wishes to issue firmware-specific calls to a device, it should 
  101. look at the high byte of the device-driver table entry for that device to 
  102. obtain the proper place to check firmware ID bytes.  In the sample code above, 
  103. the high byte would be returned in addr+1.  For devices mirrored to slot 2 
  104. from slot 5, this technique will return $C5, and ID bytes would then be 
  105. checked (since they should always be checked before making device-specific 
  106. calls) in the $C500 space.  Applications ignoring this technique will 
  107. incorrectly check the $C200 space.
  108.  
  109.  
  110. Further Reference
  111. o    ProDOS 8 Technical Reference Manual
  112. o    ProDOS 8 Technical Note #21, Identifying ProDOS Devices
  113.